ETSITS124 642V8.11.0 



(2013-07) 




Digital cellular telecommunications system (Phase 2+); 
Universal Mobile Telecommunications System (UMTS); 

LTE; 

Completion of Communications to Busy Subscriber (CCBS) 

and Completion of Communications by No Reply (CCNR) 

using IP Multimedia (IM) Core Network (CN) subsystem; 

Protocol specification 
(3GPP TS 24.642 version 8.11.0 Release 8) 



^ 



35^ ite. 



A GLOBAL I M ITI ATI VE 



3GPP TS 24.642 version 8.1 1 .0 Release 8 1 ETSI TS 1 24 642 V8.1 1 .0 (201 3-07) 



Reference 



RTS/TSGC-01 24642v8b0 
Keywords 



GSM,LTE,UMTS 



£75/ 

650 Route des Lucioles 
F-06921 Sophia Antipolis Cedex - FRANCE 

Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 

Siret N°348 623 562 00017 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N° 7803/88 



Important notice 



Individual copies of the present document can be downloaded from: 
http://www.etsi.orq 

The present document may be made available in more than one electronic version or in print. In any case of existing or 

perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). 

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive 

within ETSI Secretariat. 

Users of the present document should be aware that the document may be subject to revision or change of status. 

Information on the current status of this and other ETSI documents is available at 

http://portal.etsi.orq/tb/status/status.asp 

If you find errors in the present document, please send your comment to one of the following services: 

http://portal.etsi.orq/chaircor/ETSI support.asp 

Copyright Notification 

No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 

© European Telecommunications Standards Institute 2013. 
All rights reserved. 

DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members. 
3GPP™and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and 

of the 3GPP Organizational Partners. 
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association. 



ETSI 



3GPP TS 24.642 version 8.11.0 Release 8 2 ETSI TS 124 642 V8.11.0 (2013-07) 



Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://ipr.etsi.org) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). 

The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or 
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. 

The cross reference between GSM, UMTS, 3 GPP and ETSI identities can be found under 
http://webapp.etsi.org/key/queryform. asp . 



ETSI 



3GPP TS 24.642 version 8.11.0 Release 8 3 ETSI TS 124 642 V8.11.0 (2013-07) 



Contents 



Intellectual Property Rights 2 

Foreword 2 

Foreword 5 

1 Scope 6 

2 References 7 

3 Definitions and abbreviations 7 

3.1 Definitions 7 

3.2 Abbreviations 8 

4 Completion of Communications to Busy Subscriber (CCBS) / Completion of Communication on 

No Reply (CCNR) 9 

4.1 Introduction 9 

4.2 Description 9 

4.2.1 General description 9 

4.3 Operational requirements 10 

4.3.1 Provision/withdrawal 10 

4.4 Coding requirements 10 

4.5 Signalling requirements 10 

4.5.1 Activation/deactivation 10 

4.5.2 Registration/erasure 10 

4.5.3 Interrogation 10 

4.5.4 Invocation and operation 10 

4.5.4.1 Actions at the originating UE 10 

4.5.4.2 Actions at the originating AS 1 

4.5.4.2.0 General 1 

4.5.4.2.1 CC Invocation 1 

4.5.4.2.1.1 Normal procedures 1 

4.5.4.2.1.1.1 Detecting if CC is possible 1 

4.5.4.2.1.1.2 Starting of the service retention procedure 1 

4.5.4.2.1.1.3 CC service invocation by user A 12 

4.5.4.2.1.1.4 Stopping of the service retention procedure 12 

4.5.4.2.1.1.5 Sending of the CC invocation request to the terminating AS 12 

4.5.4.2.1.1.6 Procedures after CC invocation confirmation from the terminating AS 13 

4.5.4.2.1.2 Exceptional procedures 13 

4.5.4.2.2 CC Revocation 13 

4.5.4.2.2.1 Normal procedures 13 

4.5.4.2.2.1.1 Generating a revocation request 13 

4.5.4.2.2.1.2 Revocation requested by the user 13 

4.5.4.2.2.1.3 Revocation caused by timer expiry 14 

4.5.4.2.2.2 Exceptional procedures 14 

4.5.4.2.3 CC Operation 14 

4.5.4.2.3.1 Normal procedures 14 

4.5.4.2.3.2 Exceptional procedures 15 

4.5.4.2.3.2.1 Non-acceptance of CC recall 15 

4.5.4.2.3.2.2 User A is found busy or CC busy 15 

4.5.4.2.3.2.3 The caller makes another call to the same destination B 15 

4.5.4.2.3.2.4 CC call failure 16 

4.5.4.3 Actions at the terminating AS 16 

4.5.4.3.0 General 16 

4.5.4.3.1 CC possible indication 16 

4.5.4.3.1.1 Normal operation 16 

4.5.4.3.1.2 Exceptional procedures 16 

4.5.4.3.2 CC Invocation 17 

4.5.4.3.2.1 Normal operation 17 



ETSI 



3GPP TS 24.642 version 8.1 1 .0 Release 8 4 ETSI TS 1 24 642 V8.1 1 .0 (201 3-07) 

17 



4.5.4.3.2.2 Exceptional procedures 

4.5.4.3.3 CC Revocation 

4.5.4.3.3.1 Normal operation 

4.5.4.3.3.2 Exceptional procedures 

4.5.4.3.4 CC Operation 

4.5.4.3.4.1 Normal operation 

4.5.4.3.4.1.1 The callee becomes available 

4.5.4.3.4.1.2 The CC recall is started 

4.5.4.3.4.1.3 Incoming communication during the CC recall processing 

4.5.4.3.4.1.4 Procedures after the CC call was offered to the callee 

4.5.4.3.4.1.5 Further procedures 

4.5.4.3.4.2 Exceptional procedures 20 

4.5.4.4 Actions at the terminating UE 20 

4.5.5 SIP specific Event Notifications 20 

4.6 Interaction of Call-Completion with other services 20 

4.6.1 Communication waiting (CW) 20 

4.6.2 Communication Hold (HOLD) 21 

4.6.3 Terminating Identification Presentation (TIP) 21 

4.6.4 Terminating Identification Restriction (TIR) 21 

4.6.5 Originating identification presentation (OIP) 21 

4.6.6 Originating identification restriction (OIR) 21 

4.6.7 Conference calling (CONE) 21 

4.6.8 Communication diversion services (CDIV) 21 

4.6.8.1 General 21 

4.6.8.2 Communication Eorwarding Unconditional 21 

4.6.8.3 Communication forwarding busy 22 

4.6.8.4 Communication forwarding no reply 22 

4.6.8.5 Communication forwarding not registered 22 

4.6.8.6 Communication deflection (CD) 22 

4.6.9 Advice of charge (AOC) 23 

4.6.10 Completion of communications (CCBS/CCNR) 23 

4.6.11 Malicious communication identification (MCID) 23 

4.6.12 Anonymous Communication Rejection and Communication Barring (ACR/CB) 23 

4.6.13 Message Waiting Indication (MWI) 23 

4.6.14 Explicit Communication Transfer (ECT) 23 

4.6.15 Elexible Alerting (E A) 23 

4.6.16 Customized Alerting Tones (CAT) 23 

4.7 Void 23 

4.8 Parameter values (timers) 23 

4.8.1 Timers referring to the originating AS 23 

4.8.2 Timers referring to the terminating AS 24 

Annex A (informative): Signalling flows 25 

A.l CCBS activation and CCBS call 25 

A. 2 CCBS suspend and resume procedures 31 

A.3 CCNR activation 34 

A.4 CCNR call 37 

Annex B (informative): Example of filter criteria 39 

B.O General 39 

B.l Originating 39 

B.2 Terminating side 39 

Annex C (informative): Change history 40 

History 42 



ETSI 



3GPP TS 24.642 version 8.11.0 Release 8 5 ETSI TS 124 642 V8.11.0 (2013-07) 



Foreword 



This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). 

The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or 
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. 

The cross reference between GSM, UMTS, 3 GPP and ETSI identities can be found under 
http ://webapp . etsi .org/key/query f orm. asp . 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies the stage three Protocol Description of the Completion of Communications to Busy 
Subscriber (CCBS) service and the Completion of Communication on no Reply (CCNR) service, based on stage one 
and two of the ISDN supplementary services. It provides the protocol details in the IP Multimedia (IM) Core Network 
(CN) subsystem based on the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP). 

The Completion of Communications to Busy Subscriber CCBS service enables user A, encountering a busy 
destination B, to have the communication completed without having to make a new communication attempt when the 
destination B becomes not busy. 

The Completion of Communications on No Reply CCNR supplementary service enables user A, encountering a 
destination B which does not answer the communication (No Reply), to have the communication completed without 
having to make a new communication attempt when the destination becomes not busy after having initiated an activity. 

The present document is applicable to User Equipment (UE) and Application Servers (AS) which are intended to 
support the CCBS and CCNR supplementary services. 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TS 22.173 [1] and the following 
terms and definitions apply. 

busy: See ITU-T Recommendation 1.221 [8], subclause 2.1.5. 

call information retention: A procedure of network A to store the call information of a specific call so that it can be 
used for that call. 

caller: The user who originated the call and to whom the CCBS service is provided. 

callee: The user which is identified as destination B. 

CC: Completion of Communication 

CC busy: Any one of the following conditions will cause a CCBS busy condition: 

- maximum number of calls reached at user A (see ITU-T Recommendation 1.221 [8], subclause 2.1.3, item 2)); 

- no resources (bandwidth) available at user A; 

- CC recall pending on user A. 
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CCBS/CCNR call: A call generated by the network connecting the caller to the callee, resulting from the callers' 
acceptance of a CCBS/CCNR recall. 

CCBS/CCNR recall: An indication informing the caller that the network is ready to initiate a CCBS/CCNR call to the 
callee and that the network is awaiting a response to this indication. 

CCBS/CCNR request: An instance of an activation of the CCBS/CCNR service which is held in a queue pending the 
correct conditions for the CCBS/CCNR service to be completed. 

Suspended CCBS/CCNR request: A CCBS/CCNR request which cannot be served even if the callee is in the 
appropriate state because the caller is busy. 

CCBS/CCNR request retention: If an attempt to establish a CCBS/CCNR call fails because the destination is busy 
again, then the network provider option "CC request retention" defines whether the CCBS supplementary service is 
continued or not, i.e. if the "CC request retention" is supported, the original CCBS/CCNR request retains its position in 
the queue B, and monitoring of user B shall continue. Otherwise the CCBS/CCNR request is revocated. 

CC service duration timer: A maximum time the CC service will remain activated for the caller within the network. 

destination B: The entity addressed in the original call. 

long-term denial: The network cannot accept user A's request to activate the CC service and a later attempt to activate 
the CC service for the same destination B will also be rejected. 

queue A: A buffer at the originating side for the control of CCBS/CCNR requests associated with the caller. 

queue B: A buffer at the terminating side for the control of CCBS/CCNR requests associated with destination B. 

retain option: The retain option, if supported in both the originating and destination network, will maintain the 
CCBS/CCNR request in the destination B queue, if a CCBS/CCNR call has failed due to destination busy condition. 

short-term denial: The network temporarily cannot accept user A's request to activate the CC service. A later attempt 
to activate the CC service for the same destination B may succeed. 

UE-A: The caller"s UE. 

UE-B: The callee" s UE. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AOC Advice Of Charge 

AS Application Server 

CB Communication Barring 

CC Completion of Communications 

CCBS Completion of Communication to Busy Subscriber 

CCNR Completion of Communications on No Reply 

CD Communication Deflection 

CDIV Call Diversion 

CFB Communication Forwarding Busy 

CFNL Communication Forwarding on No Logged-in 

CFU Communication Forwarding Unconditional 

CN Core Network 

CNR Completion of communication on No Reply 

CONE CONFerence calHng 

CS Circuit Switched 

CW Communication Waiting 

ECT Explicit Communication Transfer 

HOLD Communication HOLD 

IFC Initial Filter Criteria 

IM IP Multimedia 

IMS IP Multimedia Subsystem 

IP Internet Protocol 



ETSI 



3GPP TS 24.642 version 8.11.0 Release 8 



ETSI TS 124 642 V8.11.0 (2013-07) 



ISDN 

MCID 

MIME 

OIP 

OIR 

PLMN 

PSTN 

SIP 

TIP 

TIR 

UE 



Integrated Service Data Network 
Malicious Communication IDentification 
Multipurpose Internet Mail Extensions 
Originating Identification Presentation 
Originating Identification Restriction 
Public Land Mobile Network 
Public Switch Telephone Network 
Session Initiation Protocol 
Terminating Identification Presentation 
Terminating Identification Restriction 
User Equipment 



Completion of Communications to Busy Subscriber 
(CCBS) / Completion of Communication on No Reply 
(CCNR) 



4.1 



Introduction 



The CCBS and CCNR services enables a user, encountering a destination that is busy or does not answer, to have the 
communication completed at a later point in time without the user having to manually initiate a new communication 
attempt. 

4.2 Description 
4.2.1 General description 

The CCBS service enables user A, encountering a busy destination B, to have the communication completed without 
the user having to manually initiate a new communication attempt when the destination B becomes not busy. 

When user A requests the CCBS supplementary service, the network will monitor for destination B becoming free 
again. 

When destination B becomes free again, the network will wait a short time in order to allow the resources to be re-used 
for originating a communication. If the resources are not re-used by destination B within this time, the network will 
automatically recall user A. 

When user A accepts the CCBS recall, the network will automatically generate a CCBS call to destination B. 

The CCNR supplementary service enables user A, encountering a destination B which does not answer the 
communication (No Reply), to have the communication completed without the user having to manually initiate a new 
communication attempt when the destination becomes not busy after having initiated and completed a new 
communication. 

When user A encounters a destination B which does not answer the communication (No Reply), user A can request the 
CCNR supplementary service. 

When user A requests the CCNR supplementary service, the network will monitor for destination B becoming not busy 
after having initiated and completed a new communication. 

When destination B becomes not busy after having initiated and completed a new communication, the network will wait 
a short time (as defined by the destination B idle guard timer) in order to allow the resources to be reused for originating 
a communication. If the resources are not reused by destination B within this time, the network will automatically recall 
user A. 

When user A accepts the CCNR recall, then the network will automatically generate a CCNR call to destination B. 
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The CCBS / CCNR service control is done by the appHcation servers. It is possible to modify the queue by the users 
(add entry, delete entries, delete whole queue) by usage of appropriate procedures. 

On the originating side the originating AS A manages the queue of user A and on terminating side the terminating AS B 
manages the queue of outstanding communications towards UE B. 

The originating AS keeps track of the CCBS/CCNR requests started by each user for a given period of time, and rejects 
a new request in case the provisioned limit has been overcome. 

The terminating AS keeps track of the CCBS /CCNR requests directed to each user for a given period of time, and 
rejects a new request in case the provisioned limit has been overcome. 

After successful CCBS/CCNR Call setup the respective entry is deleted in both queues. Also a proper management of 
the queue in the suspend/resume scenario upon reception of the corresponding message takes place. 

4.3 Operational requirements 
4.3.1 Provision/withdrawal 

The CCBS/CCNR service is provided to the served user after prior arrangement with the service provider, or as a 
service provider option. Withdrawal of these services is made on the served user's request or for service provider 
reasons. 

4.4 Coding requirements 

No specific requirements needed. 

4.5 Signalling requirements 

4.5. 1 Activation/deactivation 

The call completion services are individually activated at provisioning or at the subscriber's request. 
The call completion services are individually deactivated at withdrawal or at the subscriber's request. 

4.5.2 Registration/erasure 

The CCBS/CCNR service requires no registration. Erasure is not applicable. 

4.5.3 Interrogation 

For the interrogation of the call-completion services the Ut interface using XC AP as enabling protocol as described in 
3GPP TS 24.623 [4] or SIP based user configuration as described in 3GPP TS 24.238 [7] in combination with 
announcement procedures according to 3GPP TS 24.628 [3] could be used. 

4.5.4 Invocation and operation 
4.5.4.1 Actions at the originating UE 

Basic call procedures and in case of a call-completion recall initiated by a REFER request, normal REFER method 
handling procedures according to 3 GPP TS 24.229 [2] shall apply. 

For invoking and revoking of the call completion services, announcement procedures according to 3GPP TS 24.628 [3] 
and inband-interaction procedures should be used. 
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Editor's note: The usage of inband interaction procedures needs further studies and specification. For invoking and 
revoking of the call-completion services also out-of-band stimulus procedures according to ETSI TR 183 
057 [4] could be used. 

4.5.4.2 Actions at the originating AS 

4.5.4.2.0 General 

The originating AS shall operate as a SIP proxy as specified in subclause 5.7.4 of 3GPP TS 24.229 [2] or operate as a 
routing B2BUA as specified in subclause 5.7.5 of 3GPP TS 24.229 [2] for the incoming INVITE request and all future 
requests and responses in the same dialog. 

4.5.4.2.1 CC Invocation 
4.5.4.2.1 .1 Normal procedures 

4.5.4.2.1 .1 .1 Detecting if CC is possible 

When in case of CCBS a 486 (Busy Here) response has been received from the terminating network, and the following 
set of conditions apply: 

- the 486 (Busy Here) response contains an Call-Info header field with a "purpose" header field parameter set to 
"call-completion"; and 

- the user A CCBS queue limit has not been exceeded; and 

- CCBS has not been activated for an identical communication (network option), determined by the stored basic 
communication information defined in subclause 4.5.4.2.1.1.2; and 

- there are no service interactions that preclude CCBS; 

then the service retention procedure as specified in subclause 4.5.4.2.1.1.2 is executed. 

When in case of CCNR a 1 80 (Ringing) response has been received from the terminating network, and the following set 
of conditions apply: 

- the 180 (Ringing) response contains an Call-Info header with a purpose parameter set to 'call-completion'; and 

- the user A CCNR queue limit has not been exceeded; and 

- CCNR has not been invoked for an identical communication (network option), determined by the stored basic 
communication information defined in subclause 4.5.4.2.1.1.2; and 

- there are no service interactions that preclude CCNR, 

then the originating AS shall remove the Call-Info header from the 1 80 (Ringing) response, forward it to UE- A and start 
the CC no-reply timer CCNR-T5. When this timer expires then the service retention procedure as specified in 
subclause 4.5.4.2.1.1.2 is executed. 

4.5.4.2.1 .1 .2 Starting of the service retention procedure 

The originating AS shall start the retention timer CC-Tl. The originating AS shall retain the following information from 
the original communication, if available: 

1) SDP offer, and 

2) Request-URI, and 

3) To header field, and 

4) From header field, and 

5) Privacy header field, and 
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6) P-Asserted-ID header field. 

4.5.4.2.1 .1 .3 CC service invocation by user A 

For the invocation of the CC service, in case of CCBS immediately after receipt of a 486 (Busy Here) response with a 
CCBS possible indication or in case of CCNR after receipt of a 180 (Ringing) response with a CCNR possible 
indication upon expiry of the No-Reply timer CCNR-T5, the originating AS shall provide an announcement that CC is 
possible to user A, according to 3GPP TS 24.628 [3], followed by inband-interaction procedures for the activation 
confirmation. 

NOTE: User A can have a limited number of CC requests outstanding. This limit is a network provider option 
(with a maximum value of 5). 

If user A does not confirm the activation of CC, the AS shall restore the communication condition from before the 
announcement and proceed with basic communication procedures by forwarding the 486 (Busy here) response in case 
of CCBS or sending a 199 (Early Dialog Terminated) on the announcement dialog in case of CCNR. 

4.5.4.2.1 .1 .4 Stopping of the service retention procedure 

On receiving a CC invocation confirmation from user A before the expiry of the retention timer CC-Tl, the originating 
AS shall: 

a) stop the retention timer CC-Tl ; and 

b) store the retained call information from the original basic communication. 

As a network option, in case of receipt of a CCNR invocation confirmation, the originating AS may terminate the 
original communication by sending a CANCEL request to UE-B, in accordance with the procedures described in 
3GPPTS 24.229 [2]. 

NOTE: The above procedure avoids a race condition between answering the call at the terminating side and 
subscribing to CCNR at the originating side. 

4.5.4.2.1 .1 .5 Sending of the CC invocation request to the terminating AS 

The originating AS shall send a SUBSCRIBE request to the terminating AS according to RFC 3265 [6] and 
RFC 6910 [5]. The originating AS shall populate the SUBSCRIBE request as follows: 

- a Request-URI set to the URI returned by the terminating AS in the Call-Info header field of the response 
including the CC possible indication 

- in case of CCBS as received in the Call-Info header field in the 486 (Busy Here) response, including an "m" 
SIP URI parameter with a value set to "BS"; 

in case of CCNR as received in the Call-Info header in the 180 (Ringing) response, including an "m"- SIP 
URI parameter with a value set to "NR"; 

- a From header field set to the URI of UE-A from the original communication; 
a To header field set to the URI of UE-B from the original communication; 

- a Contact header field set to the URI of the originating AS; 

- a Call-Info header field with the URI of UE-A from the P-Asserted-Identity, a "purpose" header field parameter 
set to "call-completion", and an m-parameter set to "BS" in case of CCBS or "NR" in case of CCNR; 

- a P-Asserted-Identity header field as received from the original INVITE request; and 

NOTE 1 : If available and to avoid interworking problems (e.g. if the called user is in the PSTN) a P-Asserted- 
Identity header field that contains an E.164 number is preferable. 

- an Expires header field set to at least the initial value of the service duration timer CC-T3. 
The originating AS shall start the CC request timer CC-T2. 



ETSI 



3GPP TS 24.642 version 8.11.0 Release 8 13 ETSI TS 124 642 V8.11.0 (2013-07) 

NOTE 2: The To header field is used to identify a particular CC target. 

4.5.4.2.1 .1 .6 Procedures after CC invocation confirmation from the terminating AS 

If the originating AS receives a NOTIFY request as an answer to an outstanding CC request which was described in 
subclause 4.5.4.2.1.1.5 with the cc-state parameter set to 'queued', the originating AS shall: 

a) stop the CC request timer CC-T2; 

b) start the CC service duration timer CC-T3; 

c) store the information whether the cc- service-retention parameter has been received or not; and 

d) confirm to the caller that the invocation was successful, using announcement procedures according to 
3GPPTS 24.628 [3]. 

In case of CCBS the originating AS shall forward the 486 (Busy Here) response to UE-A. 

In case of CCNR, if the original communication with the UE-B has already been cancelled by the originating AS, the 
originating AS shall send a 480 (Temporarily unavailable) response to UE-A. 

4.5.4.2.1 .2 Exceptional procedures 

If the originating AS receives a 480 (Temporarily Unavailable) response (short term denial) or a 403 (Forbidden) 
response (long term denial), in accordance with the procedures of subclause 4.5.4.3.2.2, to an outstanding CC request 
which was described in subclause 4.5.2.2.1.1.5, then the originating AS shall: 

a) stop the CC request timer CC-T2; and 

b) confirm to the caller that the invocation was not successful, using announcement procedures according to 
3GPPTS 24.628 [3]. 

In case of CCBS the originating AS shall forward the 486 (Busy Here) response to UE-A. 

4.5.4.2.2 CC Revocation 

4.5.4.2.2.1 Normal procedures 

4.5.4.2.2.1 .1 Generating a revocation request 

For revoking the CC service, the originating AS shall send a SUBSCRIBE request to the terminating AS according to 
RFC 3265 [6] and RFC 6910 [5] in the SUBSCRIBE dialog. The originating AS shall populate the SUBSCRIBE 
request following normal procedures as specified in 3 GPP TS 24.229 [2] with the following additions: 

- a Call-Info header field with the URI of UE-A from the P-Asserted-Identity, a "purpose" header field parameter 
set to "call-completion", and an m-parameter set to "BS" in case of CCBS or "NR" in case of CCNR; 

- a P-Asserted-Identity header field as received from the original INVITE request; 

NOTE: If available and to avoid interworking problems (e.g. if the called user is in the PSTN) a P-Asserted- 
Identity header field that contains an E.164 number is preferable. 

and 

- an Expires header field set to zero. 

4.5.4.2.2.1 .2 Revocation requested by the user 

If the originating AS receives a revocation request by the user, the originating AS shall 

- construct a SUBSCRIBE request according to subclause 4.5.4.2.2.1.1; and 

- send the SUBSCRIBE request to the terminating AS; and 
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- inform user A of the result of the revocation by using announcement procedures and inband-interaction 
procedures according to 3GPP TS 24.628 [3]. 

4.5.4.2.2.1 .3 Revocation caused by timer expiry 

If the service-duration timer CC-T3 expires, the originating AS shall: 

- construct a SUBSCRIBE request according to subclause 4.5.4.2.2. 1.1; and 

- send the SUBSCRIBE request to the terminating AS. 

4.5.4.2.2.2 Exceptional procedures 

The originating AS shall be prepared to receive a NOTIFY request cause by a service-duration timer expiry at the 
terminating AS, according to the procedures of subclause 4.5.4.3.3.2, with: 

- the Subscription-State header field set to "terminated"; and 

- the "reason" Subscription-State header field parameter set to "noresource". 

In this case the originating AS shall stop the CC service-duration timer CC-T3, if this timer is still running. 

4.5.4.2.3 CC Operation 

4.5.4.2.3.1 Normal procedures 

On receipt of a CC recall notification as described in subclause 4.5.4.3.4.1.2, and if user A is neither busy nor CC busy, 

the originating AS shall initiate the CC recall to user A by sending a REFER request to UE-A according to 

3GPP TS 24.229 [2], and shall start the recall timer CC-T4. The originating AS shall populate the REFER request as 

follows: 

a Request-URI set to the URI of UE-A from the original communication, including an "m" SIP URI parameter 
with a value set to "BS" in case of CCBS or "NR" in case of CCNR; and 

- a Refer-to header set to the URI of UE-B . 

If there are multiple outstanding CC requests at the originating AS, then the correct target for the CC recall is identified 
using standard SIP dialog identification procedures. 

In the case UE-A does not support the REFER method extension, the special REFER request handling procedures 
according to 3GPP TS 24.628 [3] should be used. As a network option, e.g. in the case the originating AS has 
knowledge that UE-A does not support the REFER method extension, the originating AS may start the 3rd party call 
control procedures according to 3GPP TS 24.628 [3] without waiting for a 3xx - 6xx response. In this case, the 
originating AS shall send an INVITE request with a Request-URI set to the URI of UE-A from the original 
communication, including a "m" SIP URI parameter with a value set to "BS" in case of CCBS or "NR" in case of 
CCNR. The INVITE request shall include identity information about user B in the From header field as received in the 
To header field of the original request. Other identity information may be included if allowed by the Privacy settings in 
the response of the original communication. 

If user A accepts the recall before the CC recall timer expires (a NOTIFY request with a body containing SIP/2.0 100 
Trying or a 200 OK to the 3pcc INVITE request according to the special REFER request handling procedures according 
to 3GPP TS 24.628 [3] is received), the originating AS shall stop timer CC-T4 and initiate the CC call to destination B 
by sending an INVITE request, in accordance with RFC 6910 [5]. The originating AS shall populate the INVITE 
request as follows. 

- a Request-URI set to the URI of UE-B from the original communication, including an "m" SIP URI parameter 

- set to "BS" in case of CCBS; or 

- set to "NR" in case of CCNR; 

a From header field set to the URI of UE-A from the original communication; 

- a To header field set to the URI of UE-B from the original communication; 
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- a Call-Info header field with the URI of UE-A from the P-Asserted-Identity in the original communication, a 
"purpose" header field parameter set to "call-completion", and an m-parameter set to "BS" in case of CCBS and 
"NR"incaseofCCNR. 



4.5.4.2.3.2 Exceptional procedures 

4.5.4.2.3.2.1 Non-acceptance of CC recall 

See subclause 4.5.4.2.2.1.3. 

4.5.4.2.3.2.2 User A is found busy or CC busy 

If the caller is found to be busy or CC busy, when a CC recall notification as described in subclause 4.5.4.3.4.1.2 has 
been received, then the originating AS shall suspend the CC request until the caller becomes not busy or not CC busy 
again. The originating AS shall send a PUBLISH request to the terminating AS according to RFC 6910 [5] in the 
existing SUBSCRIBE dialog. The originating AS shall populate the PUBLISH request following normal procedures as 
specified in 3GPP TS 24.229 [2] with the following additions: 

- a Request-URI set to the contact address of the terminating AS returned by the terminating AS when the 
SUBSCRIBE dialog was created; 

- a Call-Info header field with the URI of UE-A from the P-Asserted-Identity in the original communication, a 
"purpose" header field parameter set to "call-completion", and an m-parameter set to "BS" in case of CCBS and 
"NR"incaseofCCNR; 

- a P-Asserted-Identity header field as received from the original INVITE request; 

NOTE 1 : If available and to avoid interworking problems (e.g. if the called user is in the PSTN) a P-Asserted- 
Identity header field that contains an E.164 number is preferable. 

- an Expires header field set to the current value of the remaining duration of the subscription; and 

- a body set to a PIDF informing about the basic state 'closed' for the caller's identity as presentity. 

When the caller is no longer busy or CC busy, then the originating AS shall resume the CC request. The originating AS 
shall send a PUBLISH request to the terminating AS according to RFC 6910 [5] in the existing SUBSCRIBE dialog. 
The originating AS shall populate the PUBLISH request following normal procedures as specified in 
3GPP TS 24.229 [2] with the following additions: 

- a Request-URI set to the contact address of the terminating AS returned by the terminating AS when the 
SUBSCRIBE dialog was created; 

- a Call-Info header field with the URI of UE-A from the P-Asserted-Identity in the original communication, a 
"purpose" header field parameter set to "call-completion", and an m-parameter set to "BS" in case of CCBS and 
"NR"incaseofCCNR; 



- a P-Asserted-Identity header field as received from the original INVITE request; 

NOTE 2: If available and to avoid interworking problems (e.g. if the called user is in the PSTN) a P-Asserted- 
Identity header field that contains an E.164 number is preferable. 

- an Expires header field set to the current value of the remaining duration of the subscription; and 

- a body set to a PIDF informing about the basic state 'open' for the caller" s identity as presentity. 

In case the originating AS has sent several suspension requests to different terminating ASs and the caller becomes 
neither busy nor CC busy, the originating AS shall resume each suspended request. 

4.5.4.2.3.2.3 The caller makes another call to the same destination B 

If the caller initiates another communication to the same destination B and activates the same CC service (CCBS or 
CCNR) again, then: 

- if the two communications are identical, then the following network provider option exists: 
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1) the originating AS shall retain the original request with the current request being discarded and inform the 
caller that the request has not been accepted because a CC request had already been stored against the 
requested destination B; or 

2) the originating AS shall treat this as a new CC request; and 

- if the two calls are not identical, then the originating AS shall treat this as a new CC request. In order to decide 
that the two calls are identical, the originating AS shall only compare the basic communication information, i.e. 
the SDP offer, the destination selection information, and calling user identity (if any). 

NOTE: It is a network provider option which information is used to identify identical communications. 

4.5.4.2.3.2.4 CC call failure 

If the CC call fails, the originating AS shall inform the caller as for the basic communication procedures. 

If CC is possible (a received 180 (Ringing) or 486 (Busy Here)) response contains a Call-Info header field with a 
purpose parameter set to "call-completion"), two possibilities exist: 

- if the retain option is supported across the networks (the originating AS has received a cc- service-retention 
parameter in the NOTIFY request described in subclause 4.5.4.3.2.1), the originating AS shall keep the 
transaction resources and shall not restart the service duration timer CC-T3. If the caller attempts to activate CC 
again, the originating AS shall treat this as described in subclause 4.5.4.2.3.2.3. 

- if the retain option is not supported across the networks, the originating AS shall release the transaction 
resources. The originating AS shall deactivate the CC request and shall inform the caller accordingly. 

If CC is not possible (a received 180 (Ringing) or 486 (Busy Here)) response does not contain a Call-Info header field 
with a purpose parameter set to 'call-completion'), the originating AS shall deactivate the CC request according to the 
procedures described in subclause 4.5.4.2.2 and shall inform the caller accordingly. 

4.5.4.3 Actions at the terminating AS 

4.5.4.3.0 General 

The terminating AS shall operate as a SIP proxy as specified in subclause 5.7.4 of 3GPP TS 24.229 [2] or operate as a 
routing B2BUA as specified in subclause 5.7.5 of 3GPP TS 24.229 [2] for the incoming INVITE request and all future 
requests and responses in the same dialog. 

4.5.4.3.1 CC possible indication 

4.5.4.3.1 .1 Normal operation 

When on a incoming communication the terminating AS supports the CCNR service, then the terminating AS shall 
insert a Call-Info header field with either the URI of the terminating AS or the URI received in the original INVITE 
request, a purpose-parameter set to 'call-completion', and a m-parameter set to 'NR' in the 180 (Ringing) response 
forwarded by the AS to indicate whether CCNR is possible or not, in accordance with RFC 6910 [5]. 

When on a incoming communication the callee is found to be busy and the terminating AS supports the CCBS service, 
then the terminating AS shall insert a Call-Info header field with either the URI of the terminating AS or the URI 
received in the original INVITE request, a "purpose" header field parameter set to "call-completion", and a m-parameter 
set to "BS" in the 486 (Busy Here) response generated by the terminating AS (in case of 'network determined user 
busy') or forwarded by the terminating AS (in case of 'user determined user busy') to indicate whether CCBS is possible 
or not, in accordance with RFC 6910 [5]. 

If the terminating AS knows that the CC is not possible on destination B, the terminating AS shall not include a Call- 
Info header field with a "purpose" header field parameter set to "call-completion" in any response sent to the originating 
side. 

4.5.4.3.1 .2 Exceptional procedures 

Not applicable 
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4.5.4.3.2 CC Invocation 

4.5.4.3.2.1 Normal operation 

Several CC requests can be queued against one destination B in the destination B CC queue (queue B). The exact size 
of queue B (from 1 to 5 entries) is a destination network operator option. 

As a network option the destination network operator can reduce the sizes of the CC queues associated with individual 
users. The reduced size can be zero. The size of the CCBS queue can also be related to the size of the CCNR queue if 
existing. 

On receipt of a CC invocation request as described in subclause 4.5.4.2.1.1.5, the terminating AS shall: 

a) acknowledge the receipt of the SUBSCRIBE request with a 202 Accepted response. The terminating AS shall set 
the Expires header field in the 202 Accepted response to a value less or equal of value of the Expires header field 
in the received SUBSCRIBE request, in accordance with RFC 3265 [6]. 

b) check if the Request-URI of the SUBSCRIBE request is available for the requested CC service; if there is no 
match, the terminating AS shall check if the URI in the To header field of the SUBSCRIBE request is available 
for the requested CC service; if it is available, the terminating AS shall store the information received in the CC 
invocation request in the destination B queue and send a NOTIFY request to the originating AS according to 
RFC 6910 [5]. The terminating AS shall populate the NOTIFY request as follows: 

- a Request-URI set to the URI of the originating AS as received in the Contact header field of the 
SUBSCRIBE request; 

- a To header field set to the URI of UE-A as received in the From header field of the SUBSCRIBE request; 

- a From header field set to the URI of UE-B as received in the To header field of the SUBSCRIBE request; 

- a Subscription-State header field set to "active"; 

- the "expires" Subscription-State header field parameter set to the current value of the subscription duration, 

- a body set to a cc-state parameter set to 'queued'; and 

- if the retain option is supported at the terminating AS, a cc-service-retention parameter in the same body; 

c) start the service duration timer CC-T7; and 

d) monitor destination B 

- in case of CCBS for becoming not busy; or 

- in case of CCNR for becoming not busy after having initiated an activity. 

NOTE: Methods for monitoring the callee for becoming not busy are a network provider implementation option. 

4.5.4.3.2.2 Exceptional procedures 

When the invocation of the requested CC service is rejected by the terminating AS, in accordance with RFC 6910 [5] 
the terminating AS shall send a 480 (Temporarily Unavailable) response (short term denial) or a 403 (Forbidden) 
response (long term denial), in the following cases: 

- if there are already the maximum number of requests queued against destination B ; 

if there is an interaction with other services which prevents the invocation of the requested CC service; 

- if the URI in the To header field of the SUBSCRIBE request is not available for the requested CC service at 
destination B. 

If the callee is no longer busy when the CCBS invocation request arrives, the terminating AS shall apply the normal CC 
invocation procedures as described in subclause 4.5.4.3.2.1. 

If the callee has answered the communication when the CCNR invocation request arrives, the terminating AS shall 
apply the normal CC revocation procedures as described in subclause 4.5.4.3.3.1. 
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NOTE: A general error, e. g. a syntax error, or a non-compliance to the call-completion event-package, is 
answered according to the procedures described in RFC 3265 [6]. 

4.5.4.3.3 CC Revocation 

4.5.4.3.3.1 Normal operation 

On receipt of a CC revocation request as described in subclause 4.5.4.2.2.1.1, the terminating AS shall delete the CC 
request from the destination B queue. and send a NOTIFY request to the originating AS according to RFC 3265 [6] and 
RFC 6910 [5]. The terminating AS shall populate the NOTIFY request as follows: 

- a Request-URI set to the URI of the originating AS as received in the Contact header field of the SUBSCRIBE 
request; 

a To header field set to the URI of UE-A as received in the From header field of the SUBSCRIBE request; 

- a From header field set to the URI of UE-B as received in the To header field of the SUBSCRIBE request; 

- a Subscription-State header field set to "terminated"; and 

- the "reason" Subscription-State header field parameter set to 'timeout'. 

4.5.4.3.3.2 Exceptional procedures 

The terminating AS shall automatically revoke a particular request for the CC service if the CC service duration 
timer CC-T7 expires. If timer CC-T7 expires, the terminating AS shall send a NOTIFY request to the originating AS as 
described in subclause 4.5.4.3.3.1 with the "reason" Subscription-State header field parameter set to 'noresource'. 

4.5.4.3.4 CC Operation 
4.5.4.3.4.1 Normal operation 

4.5.4.3.4.1 .1 The callee becomes available 

When the callee becomes not busy, then the terminating AS shall check queue B : 

a) if there is an entry in the queue currently being processed, the terminating AS shall take no further action; 

b) otherwise, the terminating AS shall examine: 

- the CCBS entries in the queue; and 

- the CCNR entries in the queue, if the callee became not busy after having initiated an activity; 

c) if an entry is suspended, the terminating AS shall take another entry; and 

d) if an entry is not suspended, the terminating AS shall select it for the CC recall. 

NOTE: The algorithm for the order addressing entries in the queue is outside the scope of this document. It need 
not be order of creation of the queue entry. 

The terminating AS shall start the destination B idle guard timer CC-T8. When the destination B idle guard timer CC- 
T8 expires, the terminating AS shall process the selected CC request. 

4.5.4.3.4.1 .2 The CC recall is started 

When processing a CC request, provided that the callee is still available, the terminating AS shall start the CC recall 
procedure. 

The CC recall procedure is defined as follows: 

- the terminating AS shall send a NOTIFY request to the originating AS according to RFC 6910 [5]. The 
terminating AS shall populate the NOTIFY request as follows: 
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- a Request-URI set to the URI of the originating AS as received in the Contact header field of the 
SUBSCRIBE request 

a To header field set to the URI of UE-A as received in the From header field of the SUBSCRIBE request; 

- a From header field set to the URI of UE-B as received in the To header field of the SUBSCRIBE request; 

- a Subscription-State header field set to "active"; 

- the "expires" Subscription-State header field parameter set to the remaining duration of the subscription; 

- a body set to a cc-state parameter set to 'ready'; and 

- the terminating AS shall start the CC recall timer CC-T9. 

4.5.4.3.4.1 .3 Incoming communication during the CC recall processing 

If the terminating AS receives an INVITE request while a CC recall is processed, the terminating AS shall check 
whether this new incoming communication includes a CC call indicator (an "m" SIP URI parameter in the Request- 
URI, or a Call-Info header field exists and includes an "m" header parameter). 

If the INVITE request includes a CC Call indicator, the terminating AS shall offer the incoming communication to the 
callee. 

If the INVITE request does not include a CC call indicator, the terminating AS shall reject the incoming communication 
by generating a 486 (Busy Here) response which includes a CC possible indication, according to the normal CC 
possible indication procedures described in subclause 4.5.4.3.1.1. 

4.5.4.3.4.1 .4 Procedures after the CC call was offered to the callee 

When the terminating AS has sent a 183 (Session Progress) response, a 180 (Ringing) response or a 200 (OK) response, 
it shall: 

- stop the timers CC-T7 and CC-T9; 

- delete the CC request from the destination B queue 

- send a CC revocation notification as described in subclause 4.5.4.3.3.2 to the originating AS; and 

- if there are further CC requests to be processed, then check whether the callee is busy: 

- if the callee is busy, the terminating AS shall take no further action; or 

- if the callee is not busy, the terminating AS shall service the queue for destination B as described above. 

4.5.4.3.4.1 .5 Further procedures 

If the originating AS resumes a CC request according to the procedures describe in subclause 4.5.4.2.3.2.2 because user 
A has become free (i.e. not busy and not CC busy), then, if the callee is available and there is no entry in the CC queue 
which is currently being processed, the terminating AS shall service the destination B queue as described above. 

If the originating AS suspends a CC request according to the procedures describe in subclause 4.5.4.2.3.2.2, the 
terminating AS shall: 

- stop timer CC-T9; and 

- send a NOTIFY request to the originating AS, including a body with a cc-state parameter set to 'queued'; and 

- attempt to process another CC request in the same queue. 

If the originating AS revokes a CC request according to the procedures described in subclause 4.5.4.2.2.1.1, the 
terminating AS shall stop timers CC-T7 and CC-T9 and attempt to process another CC request in the same queue. 
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4.5.4.3.4.2 Exceptional procedures 

a) The callee is busy when destination B idle guard timer expires: 

If, upon expiry of the destination B idle guard timer CC-T8, the callee is busy (e.g. the callee has initiated an 
outgoing communication), then the terminating AS shall defer servicing of the destination B CC queue until the 
callee becomes not busy again. 

b) The terminating AS receives a "ready" notification while processing the destination B CC queue: 

See subclause 4.6.10. 

c) The callee is busy upon arrival of the CC call: 

If the callee is busy when a CC call arrives, then the procedures depend on whether the retain option is supported 
across the networks: 

- if the retain option is not supported at the terminating AS, the terminating AS shall cancel the corresponding 
CC request; the terminating AS shall send a 486 (Busy Here) response with an Call-Info header field with a 
"purpose" header field parameter set to "call-completion" to the originating AS; if a new CCBS invocation 
request is received from the originating AS, normal procedures apply, according to subclause 4.5.4.3.2; 

- if the retain option is supported at the terminating AS, the terminating AS shall retain the original CC request 
in the queue; in this case the terminating AS shall continue to monitor destination B, shall not restart the 
timer CC-T7, shall stop timer CC-T9 and shall send a 486 (Busy Here) response with an Call-Info header 
field with a "purpose" header field parameter set to "call-completion" to the originating AS. 

d) No CC call as result: 

If no CC call results from the CC recall mechanism, the recall timer CC-T9 expires. In this case the terminating 
AS shall send a NOTIFY request to the originating AS according to RFC 3265 [6] and RFC 6910 [5]. The 
terminating AS shall populate the NOTIFY request as follows: 

- a Request-URI set to the URI of the originating AS as received in the Contact header field of the 
SUBSCRIBE request; 

- a To header field set to the URI of UE-A as received in the From header field of the SUBSCRIBE request; 

- a From header field set to the URI of UE-B as received in the To header field of the SUBSCRIBE request; 

- a Subscription-State header field set to 'terminated' and 

- the "reason" Subscription-State header field parameter set to 'rejected', 

4.5.4.4 Actions at the terminating UE 

Basic call procedures according to 3GPP TS 24.229 [2] shall apply. 

4.5.5 SIP specific Event Notifications 

SIP specific Event Notifications shall be used in accordance with RFC 3265 [6] including as referenced in 
IETF RFC 6910 [5]. 

4.6 Interaction of Call-Completion with other services 
4.6.1 Communication waiting (CW) 

The CW AS shall not invoke the CW service on a CC recall. 
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NOTE 1 : For a waiting communication, destination B is not considered as busy. 

If the communication waiting indication cannot be given at the destination B, user A will receive busy 
indication and can invoke the CCBS service to destination B. 

NOTE 2: Procedures for the case the CC call encounters busy again are described in subclause 4.5.4.3.4.2. 

4.6.2 Communication Hold (HOLD) 

No impact, i.e. neither service shall affect the operation of the other service. 

NOTE: When receiving a CC recall indication, user A can invoke the communication hold service in order to 
make interface resources available for the establishment of the CC call. 

4.6.3 Terminating Identification Presentation (TIP) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.4 Terminating Identification Restriction (TIR) 

The TIR AS shall enforce the privacy settings of the CC recall answer on the CC call and if necessary on the subsequent 
communication, if the CC recall was invoked via Spec procedures. 

4.6.5 Originating identification presentation (OIP) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.6 Originating identification restriction (OIR) 

The OIR AS shall enforce the privacy settings of the originating call on the CC call. 

The OIR AS shall enforce the privacy settings of the originating call for SUBSCRIBE and NOTIFY requests when CC 
is invoked. 

4.6.7 Conference calling (CONF) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.8 Communication diversion services (GDIV) 

4.6.8.1 General 

The CDIV AS shall not divert a CC recall. The CDIV AS shall give a CC recall to user A at user A's original location. 

4.6.8.2 Communication Forwarding Unconditional 

For CFU activated by B before A requests CC on B : 

- If user B has activated CFU, and the forwarded communication results in a call-completion condition at user C, 
the CC AS shall inform user A that CC is possible at user C. If user A activates CC and subsequently activates 
CFU, the CDIV AS shall give the CC recall to user A at his original location. 

As a network option, in case of a diversion at user B, the CC AS shall not inform user A that CC is possible. 

For CFU activated by B after A requests CC on B : 

- If user B activates CFU after user A has activated CC on user B, then the CC AS shall revoke the CC request by 
sending a NOTIFY request to the originating AS as described in subclause 4.5.4.3.3.1 with the "reason" 
Subscription-State header field parameter set to 'noresource'. The CC AS serving user A shall send a notification 
"CC cancelled" to the user A. 

As a network option, the CC AS shall suspend the CC request until user B deactivates CFU. If the service 
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duration timer CC-T7 expires before user B deactivates CFU, the CC AS shall revoke the CC request as decribed 
in subclause 4.5.4.3.3.2. 

NOTE: How the "CC cancelled" notification is send to user A is FFS. 

4.6.8.3 Communication forwarding busy 

For CFB activated by B before A requests CC: 

- If user B has activated CFB and is busy, and the forwarded communication results in a call-completion condition 
at user C, the CC AS shall inform user A that CC is possible at user C. 

As a network option, the CC AS shall inform user A that CCBS at user B is possible. 

For CFB activated by B after A requests CC on B : 

- If user B activates CFB after user A has activated CC on user B, a CC call from user A which encounters a busy 
condition at user B shall be treated as follows: 

- user B shall be considered as being busy and the CC AS shall apply the procedures of CCBS; or 
the CDIV AS shall forward the communication as a normal communication. 

4.6.8.4 Communication forwarding no reply 

For CFNR activated by B before A requests CC: 

If user B has activated CFNR and does not answer the communication, and the forwarded communication results 
in a call-completion condition at user C, the CC AS shall inform user A that CC is possible at user C. 
As a network option, the CC AS shall inform user A that CCNR at user B is possible. 

For CFNR activated by B after A requests CC on B : 

- If user B activates CFNR after user A has activated CC on user B, a CC call from user A which encounters a no 
reply condition at user B shall be treated as follows: 

- the CC AS shall apply the procedures of CCNR; or 

- the CDIV AS shall forward the communication as a normal communication. 

4.6.8.5 Communication forwarding not registered 

For CFNL activated by B before A requests CC on B: 

- If user B has activated CFNL and is not logged in, and the forwarded communication results in a call-completion 
condition at user C, the CC AS shall inform user A that CC is possible at user C. 

As a network option, the CC AS shall inform user A that CCNR at user B is possible. 

For CFNL activated by B after A requests CC on B : 

If user B activates CFNL after user A has activated CC on user B, then the CC AS shall cancel the CC request 
and shall send a notification "CCBS cancelled" to the user A. 

As a network option, the CC AS shall suspend the CC request until user B deactivates CFNL. If the service 
duration timer CC-T3 expires before user B deactivates CFNL, the CC AS shall cancel the CC request. 

NOTE: How the "CC cancelled" notification is send to user A is FFS. 

4.6.8.6 Communication deflection (CD) 

For the originating user A: 

- If a communication to the called user B is deflected to user C by the CD service and results in a call-completion 
condition at user C, the CC AS shall inform user A that CC is possible at user C. The CDIV AS shall not deflect 
a CC recall. 
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For the called user B : 

- The CDIV AS shall not deflect a CC call. 

4.6.9 Advice of charge (AOC) 

Charging information can be given for the original communication, and for the resulting CCBS communication. 

4.6.1 Completion of communications (CCBS/CCNR) 

A user can be both a "user A" and a "user B" simultaneously, i.e. that user can have activated the CC service and have 
CC requests outstanding whilst at the same time that user can be the destination of CC requests from other users. 

The CC AS shall handle CC requests activated by this user (the user's queue A) with priority over CC requests activated 
by other users on this user (the user"s queue B), see subclause 4.5.4.3.4.1.1. 

4.6.1 1 Malicious communication identification (MCID) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.12 Anonymous Communication Rejection and Communication Barring 
(ACR/CB) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.13 Message Waiting Indication (MWI) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.14 Explicit Communication Transfer (ECT) 

Editor" s note: For further studies. For ECT with REFER the transferee does not know to who he sends the INVITE, 
and if the SUBSCRIBE is sent on another dialog, the SUBSCRIBE may not reach the target AS. 

4.6.15 Flexible Alerting (FA) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.16 Customized Alerting Tones (CAT) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.7 Void 

4.8 Parameter values (timers) 

4.8.1 Timers referring to the originating AS 

CC-Tl Retention timer. This timer specifies the amount of time that the network retains the communication 

information of the original communication which was not established successfully. After being informed 
that CC is possible the caller sends a CC invocation request before expiry of this timer. The minimum 
value of this timer is 15 seconds. 
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CC-T2 CC request operation timer. Supervision of response to a CC activation request sent from the originating 

AS to the terminating AS. CC-T2 will expire if signalling is not possible, at signalling failures, or if the 
terminating AS cannot respond. The minimum value of this timer is 10 seconds. 

CC-T3 CC service duration timer. This timer specifies the maximum time the service will remain activated for 

user A. The maximum value of this timer is 180 minutes. 

NOTE: The value of the CC service duration timer can differ in the network dependent on its usage for CCBS or 
CCNR. 

CC-T4 CC recall timer. This timer specifies the maximum time the originating AS will wait for a response from 

user A to a CC recall. The maximum value of this timer is 20 seconds. 

CCNR-T5 No-reply timer. This timer specifies the maximum time after which the originating AS will provide the 

announcement that CCNR is possible, and inband activation is possible. The maximum value of this timer 
is 20 seconds. 

4.8.2 Timers referring to the terminating AS 

CC-T7 CC service duration timer CC-T7 expiry will only be meaningful if the expiry of CC-T3 has not been 

notified to the terminating AS. CC-T7 takes a longer duration than CC-T3, i.e. CC-T7 expires at 
abnormal situations only. The maximum value of this timer is 190 minutes. When CC-T7 expires, the CC 
request will be cancelled at the terminating AS as well as at the originating AS. 

NOTE: The value of the CC service duration timer can differ in the network dependent on its usage for CCBS or 
CCNR. 

CC-T8 Destination B idle guard timer. This timer specifies the amount of time the terminating AS will delay 

after destination B has become free, before initiating a CC recall towards the originating AS. The 
maximum value of this timer is 10 seconds. 

CC-T9 Recall timer. CC-T9 should expire at emergency only, i.e. the recall should be cancelled by CC-T4 at the 

originating AS if recall is not responded to. Duration of CC-T9 = 20 seconds + some seconds for CC call 
set-up. The maximum value is 30 seconds. 
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Annex A (informative): 
Signalling flows 

A.1 CCBS activation and CCBS call 
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UE-A 



Intermediate IM CN 
subsystem entities 



1. INVITE sip:UE-B 



HO. 183 Session progress 



0-AS 



2. INVITE 

3. INVITE 



T-AS 



4. INVITE 



7. 486 Busy 
Call-Info: <T-AS>; 
purpose=call-completion; 
m=BS ; 



8. 486 Busy 



h9. 183 Session progress 



IVR: CCBS possible and activation 



11. SUBSCRIBE 

12. SUBSCRIBE sip:T-AS;m=BS 
P-Asserted-ldentity:<UE-A> 
From:<UE-A> 

To:<UE-B> 

Contact:<0-AS> 

Call-lnfo:<UE-A>;purpose=call-completion;m=BS 

Event:call-completion 

I 
13. 202 Accepted 

14. 202 Accepted 



15. NOTIFY sip:0-AS 
Event:call-completion 
[cc-state:queued 
cc-service-retention] 



UE-B 



5. INVITE 
6. 486 Busy 



busy state supervision 
begins 



16. NOTIFY 
17. 200 OK 



18. 200 OK 



IVR: CCBS activated 



20. 486 Busy 



<26. REFER sip:UE-A;m=BS 
27. 200 OK » 



29. INVITE 



19. 486 Busy 



21. NOTIFY sip:0-AS 
Event:call-completion 
[cc-state: ready] 



user B becomes 
available 



22. NOTIFY 
23. 200 OK 



24. 200 OK 



^25. REFER sip:UE-A;m=BS 



28. 200 OK 



30. INVITE 

31. INVITE 



32. INVITE sip:UE-B;m=BS 
Call-lnfo:<UE-B>;purpose=call-completion;m=BS; 



33. INVITE 



Figure A.1.1: CCBS activation and CCBS call 

Figure A.1.1 shows a basic signalling flow for a CCBS activation and a CCBS call. 
Call flows 
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1 to 5: The communication is initiated by UE-A by sending an INVITE request. The Request-URI will include the 
URI of UE-B. After IFC evaluation in the S-CSCF the INVITE request is routed to the originating AS and after 
that to the terminating AS and further on to UE-B. 

Table A.1-1 : SIP INVITE request (UE to P-CSCF) 



INVITE sip:user2_public2@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 7 

Route : sip rpcscf 1 .homel .net : 7531 ; Ir; comp=sigcomp>, <sip : orig@scscf 1 .homel .net ; lr> 
Accept -Contact : * ; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
Privacy: none 

From: <sip : userl_publicl@homel . net> ; tag=171828 
To: <sip:user2_public2@home2 .net> 
Call -ID: Cb03a0s09a2sdfglkj4 90333 
Cseq: 127 INVITE 

Supported: lOOrel; precondition, gruu, 199 
Require: sec-agree 

Contact : <sip:userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765- 
00a0c91e6bf6>;+g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims .icsi .mmtel" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, INFO, REFER 
Accept : application/sdp, application/3gpp-ims+xml 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

C = IN IP6 5555: : aaa: bbb: ccc: ddd 

t = 

m=video 3400 RTP/AVP 98 99 

b=AS:75 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:98 H2 63 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap : 99 :MPVMP4V-ES 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; maxframes=2 

a=rtpmap:96 telephone -event 



6: UE-B answers with a 486 (Busy Here) response. The 486 (Busy Here) response is routed back to the terminating 
AS. 

7 to 8: The terminating AS inserts a Call-Info header field in the 486 (Busy Here) response according to the 
procedures described in RFC 6910 [5]. The Call-Info header field will contain the URI of the terminating AS 
with an "m" header field parameter set to "BS" (busy subscriber). It further includes a "purpose" header field 
parameters set to "call-completion". The 486 (Busy Here) response is routed back to the originating AS. 
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Table A.1-2: 486 (Busy Here) response (Terminating AS to S-CSCF)) 



SIP/2.0 486 Busy Here 

Via: SIP/2. 0/UDP tas.home2.net;branch= z9hG4bK332b23 . 1, SIP/2.0/UDP 
scscf 2 .home2 .net ;branch=z9hG4bK344a65 .1, SIP/2 . 0/UDP 
icscf2_s .home2 .net ;branch=z9hG4bKj 5hgrt2o, SIP/2 . 0/UDP 

scscf 1 .homel .net ;branch=z9hG4bKehuehjgt , SIP/2 . 0/UDP oas .homel .net ;branch=z9hG4bKnashds7, 
SIP/2 . 0/UDP pcscf 1 . visitedl .net ;branch=z9hG4bK240f 34 .1, 
[5555 : :aaa:bbb: ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

From: <sip : userl_publicl@homel .net>; tag=17182 8 

To: <sip:user2_public2@home2 .net>; tag=31415 9 

Call -ID: Cb03a0s09a2sdfglkj4 90333 

CSeq: 127 INVITE 

Retry-After: 3600 

Contact : <sip:user2_public2@visited2 .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765- 
00a0c91ewxyz>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 

Content -Length: 

Call -Info: <sip: tas .home2 .net>;purpose=call-completion;m=BS 



9 to 10: The originating AS sends back a 183 (Session Progress) response to UE-A and initiates IVR procedures. 
User A is informed that CCBS is possible. User A activates CCBS. 

1 1 to 12: The originating AS subscribes for the call-completion event package according to the procedures 

described in RFC 6910 [5] at the terminating AS. The originating AS generates a SUBSCRIBE request which 
Request-URI will include the URI of the terminating AS. In order to mark the SUBSCRIBE request as a request 
for CCBS, the originating AS adds the "m" SIP URI parameter with the value "BS" to the Request-URI. The 
From header field will include the caller URI. The To header field will include the callee URI. 

Table A.1-3: SUBSCRIBE request (Originating AS to S-CSCF) 



SUBSCRIBE sip: tas.home2 .net;m=BS SIP/2 . 

Via: SIP/2. 0/UDP oas .homel .net ;branch=z9hG4bKnashds7 

Max- Forwards : 7 

Route: <sip: scscf 1 .homel .net> 

P-Asserted-Identity : <sip :userl_publicl@homel .net> 

From: <sip : userl_publicl@homel .net>; tag=31415 

To: <sip:user2_public2@home2 .net> 

Call -ID: b8 9rjhnedlrf jflslj4 0a222 

Call -Info: <sip:userl_publicl@homel .net>;purpose=call-completion;m=BS 

CSeq: 61 SUBSCRIBE 

Event: call-completion 

Expires: 2700 

Contact: <sip : oas .homel .net> 

Content -Length: 



13 to 14 The terminating AS accepts the subscription and starts busy state supervision procedures on the callee. 
Table A.1-4: 202 (Accepted) response (Terminating AS to S-CSCF) 



SIP/2.0 202 Accepted 

Via: SIP/2. 0/UDP scscf2.home2.net;branch=z9hG4bK344a65.1, SIP/2.0/UDP 

icscf2_s.home2 .net ;branch=z9hG4bKj 5hgrt2o, SIP/2 . 0/UDP 

scscf 1 .homel .net ;branch=z9hG4bKehuehjgt , SIP/2 . 0/UDP oas .homel .net ;branch=z9hG4bKnashds7 
Record-Route : 
From: 

To: <sip:user2_public2@home2 . net >; tag=15 117 
Call-ID: 
CSeq: 
Event : 

Expires: 2700 

Contact: <sip: tas .home2 .net> 
Content -Length: 



15 to 18: The terminating AS sends a notification to the originating AS, according to the procedures described in 
RFC 6910 [5]. The Request-URI of the NOTIFY request will include the URI of the originating AS. The body 
contains parameters informing of the caller" s call-completion state 'queued' and the availability of the call- 
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completion service retention at the terminating AS. After confirmation of the notification the originating AS 
starts announcements procedures informing about the activation of CCBS. 

Table A.1-5: NOTIFY request (Terminating AS to S-CSCF) 



NOTIFY siproas.homel .net SIP/2.0 

Via: SIP/2. 0/UDP tas.home2 .net;branch=z9hG4bK348923 .1 

Max- Forwards : 7 

Route: <sip: scscf 2 .home2 .net> 

P-Asserted-Identity : <sip : tas .home2 .net> 

From: <sip : user2_public2@home2 .net>; tag=151170 

To: <sip:userl_publicl@homel .net>; tag=31415 

Call -ID: b8 9rjhnedlrf jflslj4 0a222 

CSeq: 42 NOTIFY 

Subscription-State: active ;expires=2699 

Event: call-completion 

Contact: <sip: tas .home2 .net> 

Content-Type : application/call-completion 

Content -Length: (...) 

cc-state: queued 
cc-service retention 



19 to 20: The originating AS forwards the 486 (Busy Here) response to UE-A. 

21 to 24: The terminating AS sends a NOTIFY request to the originating AS, according to the procedures described 
in RFC 6910 [5]. The body contains a parameter informing of the caller" s call-completion state 'ready' (for 
recall). The originating AS confirms the notification. 

Table A.1-6: NOTIFY request (Terminating AS to S-CSCF) 



NOTIFY siproas.homel .net SIP/2.0 

Via: SIP/2. 0/UDP tas.home2 .net;branch=z9hG4bK348923 .1 

Max- Forwards : 7 

Route: <sip: scscf 2 .home2 .net> 

P-Asserted- Identity : <sip: tas .home2 .net> 

From: <sip : user2_public2@home2 .net>; tag=151170 

To: <sip:userl_publicl@homel .net>; tag=31415 

Call -ID: b8 9rjhnedlrf jflslj4 0a222 

CSeq: 4 7 NOTIFY 

Subscription-State: active ;expires=1800 

Event: call-completion 

Contact: <sip: tas .home2 .net> 

Content-Type : application/call-completion 

Content -Length: (...) 

cc-state: ready 
cc-service retention 



25 to 28: The originating AS initiates the CCBS recall to UE A (by sending a REFER request, the "m" SIP URI 
parameter set to "BS" will be included in the Request-URI of the REFER request. UE-A confirms the REFER 
request. 
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Table A.1-7: REFER request (Originating AS to S-CSCF) 



REFER sip:userl_publicl@homel .net;m=BS SIP/2.0 

Via: SIP/2. 0/UDP oas.homel.net;branch=z9hG4bK23273846 

Max- Forwards : 7 

Route : <sip: scscf 1 .homel .net; lr> 

P-Asserted-Identity : <sip : oas .homel .net> 

From: <sip : oas . homel . net > ; tag=161828 

To: <sip:userl_publicl@homel .net> 

Call -ID: Cb03a0s09a2sdfglkj4 90333 

Cseq: 127 REFER 

Refer-To : <sip : user2_public2@home2 . net ;method=INVITE> 

Referred-By: <sip : oas .homel .net > 

Contact: <sip : oas .homel .net > 

Content -Length: 



29 to 30: UE-A starts the CCBS call by sending an INVITE request to UE-B. 

31 to 33: In order to mark the INVITE request as a prioritized request for call-completion, the originating AS adds 
the "m" SIP URI parameter with the value 'BS' to the Request-URL 

Table A.1-8: SIP INVITE request (Originating AS to S-CSCF) 



INVITE sip:user2_public2@home2 .net;m=BS SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc:ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 7 

Route : sip :pcscf 1 .homel .net : 7531 ; Ir; comp=sigcomp>, <sip : orig@scscf 1 .homel .net ; lr> 
Accept -Contact : * ; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
Privacy: none 

From: <sip : userl_publicl@homel . net> ; tag=171829 
To: <sip:user2_public2@home2 .net> 
Call -ID: Cb03a0s0 9a2sdfglkj4 90444 

Call -Info: <sip:userl_publicl@homel .net>;purpose=call-completion;m=BS 
Cseq: 154 INVITE 

Supported: lOOrel; precondition, gruu, 199 
Require: sec-agree 

Contact : <sip:userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765- 
00a0c91e6bg6>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims .icsi .mmtel" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept : application/sdp, application/3gpp-ims+xml 
Content-Type: application/sdp 
Content -Length: (...) 
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A.2 CCBS suspend and resume procedures 



UE-A 



Intermediate IM CN 
subsystem entities 



0-AS 



T-AS 



CCBS Recall fails, suspension 



1. PUBLISH sip:T-AS;m=BS 
P-Assertecl-lclentity:<UE-A> 
From:<UE-A> 
^To:<UE-B> 
Contact: <0-AS> 
[status_basic=closecl] 



-2. PUBLISH- 



-3. 200 OK- 



-4. 200 OK- 



5. NOTIFY sip:0-AS 
-Event: call-corn pletion- 
[cc-state:queuecl] 



UE-B 



queue entry is 
suspended 



-6. NOTIFY- 



-7. 200 OK- 



-8. 200 OK- 



supervision, A becomes not busy 



9. PUBLISH sip:T-AS;m=BS 
P-Assertecl-lclentity:<UE-A> 
From:<UE-A> 
^To:<UE-B> 
Contact: <0-AS> 
[status_basic=open] 



-10. PUBLISH- 

I 
-11. 200 OK— 



-12. 200OK- 



13. NOTIFY sip:0-AS 
-Event:call-completion- 
[cc-state:queuecl] 



queue entry is 
resumed 



-14. NOTIFY- 



-15. 200OK- 



-16. 200OK- 



Figure A.2.1 : CCBS suspend and resume procedures 

Figure A.2.1 shows a basic signalling flow for CCBS suspend and resume procedures. 

Call flows 

1 to 4: UE-A is busy and the CCBS recall fails. The originating AS initiates the suspension procedure. It generates a 
PUBLISH request according to the procedures described in RFC 6910 [5]. The Request-URI of the PUBLISH 
request includes the URI of the terminating AS. The From header field includes the URI of UE-Aand the To 
header field includes the URI of UE-B. The body of the PUBLISH request indicates the PIDF state 'closed'. 
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Table A.2-1: PUBLISH request (Originating AS to S-CSCF) 



PUBLISH sip: sip: tas.home2 .net ©hornel .net ;m=BS SIP/2.0 

Via: SIP/2. 0/UDP oas .homel .net ;branch=z9hG4bKnashds7 

Max- Forwards : 70 

Route: <sip: scscfl .homel .net> 

P-Asserted-Identity : <sip :userl_publicl@homel .net> 

From: <sip : userl_publicl@homel .net>; tag=31415 

To: <sip:user2_public2@home2 .net>; tag=151170 

Call -ID: b8 9rjhnedlrf jflslj4 0a222 

CSeq: 71 PUBLISH 

Event : presence 

Expires: 1800 

Content -Type : application/pidf +xml 

Content -Length: (...) 

<?xml version="l . 0" encoding="UTF-8" ?> 

<presence xmlns="urn: ietf :params :xml :ns :pidf " 

xmlns : rpid= "urn : ietf : params : xml : ns : pidf : rpid" 
xmlns :dm="urn: ietf : params :xml :ns :pidf : data-model" 
xmlns :pcp="urn: ietf : params :xml :ns :pidf : caps" 
xmlns : c="urn: ietf : params :xml :ns :pidf : cipid" 
entity= "pres : user2_publicl@home2 . net " > 

< tuple id="a8098a.672364762364"> 

<status> 

<basic>closed</basic> 

</status> 
</tuple> 

</presence> 



5 to 8: The terminating AS suspends the queue entry and sends a NOTIFY request to the originating AS, according 
to the procedures described in RFC 6910 [5]. The body contains a parameter informing of the caller" s call- 
completion state 'queued'. The originating AS starts busy state supervision procedures on UE-A. 

Table A.2-2: NOTIFY request (Terminating AS to S-CSCF) 



NOTIFY sip: oas. homel .net SIP/2.0 

Via: SIP/2. 0/UDP tas.home2 .net;branch=z9hG4bK348923 .1 

Max- Forwards : 7 

Route: <sip: scscf 2 .home2 .net> 

P-Asserted-Identity : <sip : tas .home2 .net> 

From: <sip : user2_public2@home2 . net >; tag=15 117 

To: <sip:userl_publicl@homel .net>; tag=31415 

Call -ID: b8 9rjhnedlrf jflslj4 0a222 

CSeq: 72 NOTIFY 

Subscription-State: active ;expires=1795 

Event: call-completion 

Contact: <sip: tas .home2 .net> 

Content-Type : application/call-completion 

Content -Length: (...) 

cc-state: queued 
cc-service retention 



9 to 12: UE-A becomes not busy. The originating AS initiates the resumption procedure. It generates a PUBLISH 
request according to the procedures described in RFC 6910 [5]. The Request-URI of the PUBLISH request 
includes the URI of the terminating AS. The From header field includes the URI of UE-A and the To header 
field includes the URI of UE-B. The body of the PUBLISH request indicates the PIDF state 'open'. 
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Table A.2-3: PUBLISH request (Originating AS to S-CSCF) 



PUBLISH sip: sip: tas.home2 .net ©hornel .net ;m=BS SIP/2.0 

Via: SIP/2. 0/UDP oas .homel .net ;branch=z9hG4bKnashds7 

Max- Forwards : 70 

Route: <sip: scscfl .homel .net> 

P-Asserted-Identity : <sip :userl_publicl@homel .net> 

From: <sip : userl_publicl@homel .net>; tag=31416 

To: <sip:user2_public2@home2 .net>; tag=151170 

Call -ID: b8 9rjhnedlrf jflslj4 0a222 

CSeq: 85 PUBLISH 

Event : presence 

Expires: 1100 

Content -Type : application/pidf +xml 

Content -Length: (...) 

<?xml version="l . 0" encoding="UTF-8" ?> 

<presence xmlns="urn: ietf :params :xml :ns :pidf " 

xmlns : rpid= "urn : ietf : params : xml : ns : pidf : rpid" 
xmlns :dm="urn: ietf : params :xml :ns :pidf : data-model" 
xmlns :pcp="urn: ietf : params :xml :ns :pidf : caps" 
xmlns : c="urn: ietf : params :xml :ns :pidf : cipid" 
entity= "pres : user2_publicl@home2 . net " > 

< tuple id="a8098a.672364762364"> 

<status> 

<basic>open</basic> 

</status> 
</tuple> 

</presence> 



13 to 16: The terminating AS resumes the queue entry and sends a NOTIFY request to the originating AS, 

according to the procedures described in RFC 6910 [5]. The body contains a parameter informing of the caller" s 
call-completion state 'queued'. 

Table A.2-4: NOTIFY request (Terminating AS to S-CSCF) 



NOTIFY sip: oas. homel .net SIP/2.0 

Via: SIP/2. 0/UDP tas.home2 .net;branch=z9hG4bK348923 .1 

Max- Forwards : 7 

Route: <sip: scscf 2 .home2 .net> 

P-Asserted-Identity : <sip : tas .home2 .net> 

From: <sip : user2_public2@home2 . net >; tag=15 117 

To: <sip:userl_publicl@homel .net>; tag=31415 

Call -ID: b8 9rjhnedlrf jflslj4 0a222 

CSeq: 86 NOTIFY 

Subscription-State: active ;expires=1095 

Event: call-completion 

Contact: <sip: tas .home2 .net> 

Content-Type : application/call-completion 

Content -Length: (...) 

cc-state: queued 
cc-service retention 
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A.3 CCNR activation 



UE-A 



Intermediate IM CN 
subsystem entities 



1. INVITE sip:UE-B 



10. 180 Ringing 



0-AS 



2. INVITE 

3. INVITE 



T-AS 



4. INVITE 



7. 180 Ringing 
Call-Info: <T-AS>; 
purpose=call-completion; 
m=NR; 



8. 180 Ringing 
Call-Info: <T-AS>; 
purpose=call-completion; 
m=NR; 



9. 180 Ringing 



IVR: CCNR possible and activation 



11. SUBSCRIBE 

12. SUBSCRIBE sip:T-AS;m=NR 
P-Asserted-ldentity:<UE-A> 
From:<UE-A> 

To:<UE-B> 

Contact:<0-AS> 

Call-Info: <UE-A>;purpose=call-completion;m=NR 

Event:call-completion 

I 
13. 202 Accepted 



14. 202 Accepted 



15. NOTIFY sip:0-AS 
Event:call-completion 
[cc-state:queued 
cc-service-retention] 



UE-B 



5. INVITE — 

6. 180 Ringing 



16. NOTIFY 
17. 200 OK 



18. 200 OK 



IVR: CCNR activated 



19. CANCEL 



28. 200 OK (CANCEL) 



33. 487 (INVITE) 
34. ACK 



20. CANCEL 

21. CANCEL 



22. CANCEL 



25. 200 OK (CANCEL) 



26. 200 OK (CANCEL) 

27. 200 OK (CANCEL) 



30. 487 (INVITE) 



31. 487 (INVITE) 

32. 487 (INVITE) 



35. ACK 

36. ACK 



37. ACK 



user B activity 
supervision begins 



23. CANCEL 

24. 200 OK (CANCEL) 



29. 487 (INVITE) 



38. ACK 



Figure A.3.1 : CCNR activation 

Figure A.3.1 shows a basic signalling flow for a CCNR activation. 



ETSI 



3GPP TS 24.642 version 8.1 1 .0 Release 8 35 ETSI TS 1 24 642 V8.1 1 .0 (201 3-07) 

Call flows 



1 to 5: The communication is initiated by UE-A by sending an INVITE request. The Request-URI will include the 
URI of UE-B. After IFC evaluation in the S-CSCF the INVITE request is routed to the originating AS and after 
that to the terminating AS and further on to UE-B. 



Table A.3-1 : SIP INVITE request (UE to P-CSCF) 



INVITE sip:user2_public2@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc:ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 7 

Route : siprpcscf 1 .homel .net : 7531; Ir; comp=sigcomp>, <sip : orig@scscf 1 .homel .net; lr> 
Accept -Contact : * ; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
Privacy: none 

From: <sip : userl_publicl@homel . net> ; tag=171828 
To: <sip:user2_public2@home2 .net> 
Call -ID: Cb03a0s09a2sdfglkj4 90333 
Cseq: 127 INVITE 

Supported: lOOrel; precondition, gruu, 199 
Require: sec-agree; replaces 

Contact : <sip:userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765- 
00a0c91e6bf6>;+g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims .icsi .mmtel" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept : application/sdp, application/3gpp-ims+xml 
Content-Type: application/sdp 
Content -Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = - 

C = IN IP6 5555: : aaa: bbb: ccc: ddd 

t = 

m=video 3400 RTP/AVP 98 99 

b=AS:75 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:98 H2 63 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap : 99 :MPVMP4V-ES 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; maxframes=2 

a=rtpmap:96 telephone -event 



6: UE-B answers with a 180 (Ringing) response. The 180 (Ringing) response is routed back to the terminating AS. 

7 to 8: The terminating AS inserts a Call-Info header field in the 180 (Ringing) response according to the procedures 
described in RFC 6910 [5]. The Call-Info header field will contain the URI of the terminating AS with a "m" 
header field parameter set to "NR" (no reply). It further includes a "purpose" header field parameter set to "call- 
completion". The 180 (Ringing) response is routed back to the originating AS. 
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Table A.3-2: 180 Ringing (Terminating AS to S-CSCF)) 



SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP tas .home2 .net ;branch= z9hG4bK332b23 . 1, SIP/2.0/UDP 
scscf2 .home2 .net ;branch=z9hG4bK344a65 .1, SIP/2 .0/UDP 
icscf2_s.home2 .net ;branch=z9hG4bKj 5hgrt2o, SIP/2 . 0/UDP 

scscf 1 .homel .net ;branch=z9hG4bKehuehjgt , SIP/2 . 0/UDP oas.homel .net ;branch=z9hG4bKnashds7, 
SIP/2 . 0/UDP pcscf 1 .visitedl .net ;branch=z9hG4bK240f 34 .1, 
[5555 : :aaa:bbb: ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

From: <sip : userl_publicl@homel .net>; tag=171828 

To: <sip:user2_public2@home2 .net>; tag=31415 9 

Call -ID: Cb03a0s09a2sdfglkj4 90333 

CSeq: 127 INVITE 

Retry-After: 3600 

Contact : <sip:user2_public2@visited2 .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765- 
00a0c91ewxyz>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 

Content -Length: 

Call -Info: <sip: tas .home2 .net>;purpose=call-completion;m=NR 



9 to 10: The originating AS removes the Call-Info header field, forwards the 180 (Ringing) response to UE-A and 
initiates IVR procedures. User A is informed that CCNR is possible. User A activates CCNR. 

1 1 to 12: The originating AS subscribes for the call-completion event package according to the procedures 

described in RFC 6910 [5] at the terminating AS. The originating AS generates a SUBSCRIBE request which 
Request-URI will include the URI of the terminating AS. In order to mark the SUBSCRIBE request as a request 
for CCNR, the originating AS adds the "m" SIP URI parameter with the value "NR" to the Request-URI. The 
From header field will include the caller URI. The To header field will include the URI of UE-B. 

Table A.3-3: SUBSCRIBE request (Originating AS to S-CSCF) 



SUBSCRIBE sip:tas.home2 .net;m=NR SIP/2.0 

via: SIP/2. 0/UDP oas.homel .net; branch=z9hG4bKnashds7 

Max- Forwards : 7 

Route: <sip: scscf 1 .homel .net> 

P-Asserted-Identity : <sip :userl_publicl@homel .net> 

From: <sip : userl_publicl@homel .net>; tag=31415 

To: <sip:user2_public2@home2 .net> 

Call -ID: b8 9rjhnedlrf jflslj4 0a222 

CSeq: 61 SUBSCRIBE 

Call -Info: <sip:userl_publicl@homel .net>;purpose=call-completion;m=NR 

Event: call-completion 

Expires: 5400 

Contact: <sip:oas .homel .net > 

Content -Length: 



13 to 14 The terminating AS accepts the subscription and starts supervision procedures on activity of the callee. 
Table A.3-4: 202 (Accepted) response (Terminating AS to S-CSCF) 



SIP/2.0 202 Accepted 

Via: SIP/2. 0/UDP scscf2 .home2 .net;branch=z9hG4bK344a65 .1, SIP/2.0/UDP 

icscf 2_s .home2 .net ;branch=z9hG4bKj 5hgrt2o, SIP/2 . 0/UDP 

scscf 1 .homel .net ;branch=z9hG4bKehuehjgt , SIP/2 . 0/UDP oas.homel .net ;branch=z9hG4bKnashds7 
Record-Route : 
From: 

To: <sip:user2_public2@home2 .net>; tag=151170 
Call-ID: 
CSeq: 
Event : 

Expires: 5400 

Contact: <sip: tas .home2 .net> 
Content -Length: 



15 to 18: The terminating AS sends a notification to the originating AS, according to the procedures described in 
RFC 6910 [5]. The Request-URI of the NOTIFY request will include the URI of the originating AS. The body 
contains parameters informing of the caller" s call-completion state 'queued' and the availability of the call- 
completion service retention at the terminating AS. After confirmation of the notification the originating AS 
starts announcements procedures informing about the activation of CCNR. 
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Table A.3-5: NOTIFY request (Terminating AS to S-CSCF) 



NOTIFY siproas.homel .net SIP/2.0 

Via: SIP/2. 0/UDP tas.home2 .net;branch=z9hG4bK348923 .1 

Max- Forwards : 7 

Route: <sip: scscf 2 .home2 .net> 

P-Asserted-Identity : <sip : tas .home2 .net> 

From: <sip : user2_public2@home2 .net>; tag=15117 

To: <sip:userl_publicl@homel .net>; tag=31415 

Call -ID: b8 9rjhnedlrf jflslj4 0a222 

CSeq: 42 NOTIFY 

Subscription-State: active ;expires=5399 

Event: call-completion 

Contact: <sip: tas .home2 .net> 

Content-Type : application/call-completion 

Content -Length: (...) 

cc-state: queued 
cc-service retention 



19 to 28: UE-A initiates the termination of the session setup by sending a CANCEL request to UE-B. 
29 to 38: UE-B terminates the session setup by sending a 487 Request terminated to UE-A. 



A.4 CCNR call 



UE-A 



Intermediate IM CN 
subsystem entities 



. REFER sip:UE-A;m=BS 
7. 200 OK 



9. INVITE 



0-AS 



T-AS 



1. NOTIFY sip:0-AS 
Event:call-completion 
[cc-state: ready] 



UE-B 



UE-B becomes available 



2. NOTIFY 
3. 200 OK 



4. 200 OK 



5. REFER sip:UE-A;m=BS 



8. 200 OK 



10. INVITE 

11. INVITE sip:UE-B;m=NR 
12. INVITE sip:UE-B;m=NR 



13. INVITE sip:UE-B 



Figure A.4.1: CCNR call 

Figure A.4.1 shows a basic signalHng flow for a CCNR operation and a CCNR call. 
Call flows 



1 to 4: The terminating AS sends a NOTIFY request to the originating AS, according to the procedures described 
in RFC 6910 [5]. The body contains a parameter informing of the caller" s call-completion state "ready" (for 
recall). The originating AS confirms the notification. 
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Table A.4-1 : NOTIFY request (Terminating AS to S-CSCF) 



NOTIFY siproas.homel .net SIP/2.0 

Via: SIP/2. 0/UDP tas.home2 .net;branch=z9hG4bK348923 .1 

Max- Forwards : 7 

Route: <sip: scscf 2 .home2 .net> 

P-Asserted-Identity : <sip : tas .home2 .net> 

From: <sip : user2_public2@home2 .net>; tag=15117 

To: <sip:userl_publicl@homel .net>; tag=31415 

Call -ID: b8 9rjhnedlrf jflslj4 0a222 

CSeq: 4 7 NOTIFY 

Subscription-State: active ;expires=1800 

Event: call-completion 

Contact: <sip: tas .home2 .net> 

Content-Type : application/call-completion 

Content -Length: (...) 

cc-state: ready 
cc-service retention 



5 to 8: The originating AS initiates the CCNR recall to UE A by sending a REFER request, the "m" SIP URI 
parameter set to "NR" will be included in the Request-URI of the REFER request. UE-A confirms the REFER 
request. 

Table A.4-2: REFER request (Originating AS to S-CSCF) 



REFER sip:userl_publicl@homel .net;m=NR SIP/2 . 

Via: SIP/2. 0/UDP oas.homel.net;branch=z9hG4bK23273846 

Max- Forwards : 7 

Route : <sip: scscf 1 .homel .net; lr> 

P-Asserted-Identity : <sip : oas .homel .net> 

From: <sip : oas . homel . net > ; tag=161828 

To: <sip:userl_publicl@homel .net> 

Call -ID: Cb03a0s09a2sdfglkj4 90333 

Cseq: 127 REFER 

Refer-To : <sip : user2_public2@home2 . net ;method=INVITE> 

Referred-By: <sip : oas .homel .net > 

Contact: <sip : oas .homel .net > 

Content -Length: 



9 to 10: UE-A starts the CCNR call by sending an INVITE request to UE-B. 

1 1 to 13: In order to mark the INVITE request as a prioritized request for call-completion, the originating AS 
adds the "m" SIP URI parameter with the value "NR" to the Request-URI, and forwards the INVITE request to 



UE-B. 



Table A.4-3: SIP INVITE request (Originating AS to S-CSCF) 



INVITE sip:user2_public2@home2 .net;m=NR SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc:ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 7 

Route : sip :pcscf 1 .homel .net : 7531 ; Ir; comp=sigcomp>, <sip : orig@scscf 1 .homel .net ; lr> 
Accept -Contact : * ; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
Privacy: none 

From: <sip : userl_publicl@homel . net> ; tag=171829 
To: <sip:user2_public2@home2 .net> 
Call -ID: Cb03a0s09a2sdfglkj4 90444 
Cseq: 154 INVITE 

Supported: lOOrel; precondition, gruu, 199 
Require: sec-agree 

Contact : <sip:userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765- 
00a0c91e6bg6>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims .icsi .mmtel" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept : application/sdp, application/3gpp-ims+xml 

Call -Info: <sip:userl_publicl@homel .net>;purpose=call-completion;m=BS 
Content-Type: application/sdp 
Content -Length: (...) 
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Annex B (informative): 
Example of filter criteria 

B.O General 

This annex provides an example of a filter criterion that triggers SIP requests that are subject to initial filter criteria 
evaluation. 



B.1 Originating 



An example of an IFC when the CCBS or CCNR services are active at the originating S-CSCF is: 
- Method: INVITE. 



B.2 Terminating side 



Examples of the IFC at the terminating S-CSCF when the user is registered and CCBS or CCNR or both are supported 
are: 

- Method: INVITE. 

- Method: SUBSCRIBE. 
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